Control system of a numerical tool machine with a reusable software structure

ABSTRACT

A control system of a numerically controlled machine tool with a software structure, the control system including a program code of a control program specific to a machine tool and a framework that is independent of an application, wherein the framework is implemented in the form of a class library that has a first set of classes that define a functional structure of the control system. A second set of classes derived from the first set of classes of the framework, wherein the second set of classes contain the program code that is specific to the machine tool and that implements application specific functions of at least one of several functional groups associated with a man-machine interface, geometry processing, an interpolator, movement processing and a programmable logic controller.

Applicants claim, under 35 U.S.C. §§ 120 and 365, the benefit ofpriority of the filing date of Oct. 12, 2000 of a Patent CooperationTreaty patent application, copy attached, Serial Number PCT/EP00/10042,filed on the aforementioned date, the entire contents of which areincorporated herein by reference, wherein Patent Cooperation Treatypatent application Serial Number PCT/EP00/10042 was not published underPCT Article 21(2) in English.

Applicants claim, under 35 U.S.C. § 119, the benefit of priority of thefiling date of Oct. 14, 1999 of a German patent application, copyattached, Serial Number 199 49 558.0, filed on the aforementioned date,the entire contents of which are incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a control system of a numeric machinetool with a reusable software structure.

2. Description of the Related Art

EP 0 524 344 B1 discloses a configurable machine tool control thatincludes several task-oriented units, for example a numerical controland a programmable logic controller, an operating unit and acommunications area with a network interface. Moreover, at least onefunctional object, which is realized in software, or in software andhardware and which can perform a function, is provided. This functionalobject is subdivided into a procedure portion, a communications portionand possibly an operating portion. In addition, at least one objectmanager is provided, which manages at least two functional objects, inparticular synchronizes their information exchange. This controlstructure is realized on at least one data processing installation,which processes the data from the functional objects and the objectmanager, and which itself is designed as a task-oriented unit. Thefunctional objects are combined into processes. In this case as manyprocesses are formed as data processing installations are provided, andone process is serviced by each data processing installation.

It is not known from EP 0 524 344 B1 to design the control system insuch a way that its principal software structure can be used again.

An object-oriented control for machine tools is known from EP 0 657 043B1, wherein a sequence of objects is formed from object classes. Basedon the control disclosed in EP 0 524 344 B1, object classes and objectsare disclosed in EP 0 657 043 B1, which are required for the realizationof a conventional functionality of a control. Parts of this are, forexample, object classes for types of processing, geometry, kinematicsand technology data, as well as control data types and an object classcalled process control. Any arbitrary number of objects can be createdfrom each object class, each of which respectively contains its own datarange, a messenger mechanism for communication with other objects, and aprocedure portion for executing methods of processing, geometry,kinematics and technology. Because of the derivation of several objectsfrom one object class, these objects partially have an identical, or atleast similar, program code which they have inherited from the objectclass. Furthermore, the object classes are also mapped as abstract datamodels in the internal control data storage, because of which abstractapplication-specific data types can be complemented, andapplication-specific object distinctions can be modified. The user inputis interpreted by the process control and leads to the activation of theselected objects. The selected objects communicate with each other and,by this network-like linkage, constitute a functional unit of thecontrol which is capable of running.

Although it is already known from EP 0 657 043 B1 to pass on propertiesof an object class to an object of this class, and to store abstractdata models for the object classes, which can be changed by theprogrammer, this only relates to the objects. Since one object alwaysimplements at least one specific function of the control, and thereforeof the machine, the objects need to have machine-specificcharacteristics, which makes them incompatible for controlling anothermachine. Therefore it is not possible as a rule to reuse objects withoutchanging them.

A CNC control system is known from EP 0 717 866 B1, which contains anobject-oriented program, in which objects exchange object-orientedinformation. The objects are divided into classes in the object-orientedprogram, for example a process class containing work processes such asdrilling, gear-cutting, broaching, etc., which are executed by machinecomponents. In this case one class always contains similar objects, i.e.objects which agree in their basic structure. Because of the uniformbasic structure of the objects of a class, there is the possibility thatselected properties of the respective class are inherited by the newobject in the course of producing new objects. A further object classincludes machine components, for example a spindle, shafts, a turntable,etc. Furthermore, object classes are provided for the kernel, with amotion and a logic controller as objects, for platform services, for theoperating system and the device driver. When operating the control it isnecessary for messages to be exchanged between the individual objects.For example, for a drilling operation a message regarding the number ofrevolutions of the drill is transmitted by the drill object to thespindle object, furthermore messages regarding the position of the holeare transmitted to the objects of the axes involved, etc. In this case astandard interface for the messages is provided, so that it has auniversal structure and can be designed independently of the objectsinvolved. With an object which receives or transmits messages regardingthe movement, this standard interface for message exchange is realizedby a software kernel, which is intended to be operated in real time andreceives and transmits messages.

It is also not disclosed in EP 0 717 866 B1, how the structure of thecontrol software is to be designed in order to make possible a reuse ofthe software design in connection with a similar numerical control.

The term framework is known from the book “Entwurfmuster” [Design Model]by Erich Gamma and Richard Helm, published in 1996 by Addison-Wesley,and the book “Objektorientierte Software—Entwicklung am Beispiel vonET++” [Object-Oriented Software Development in Accordance with theExample of ET++] by Erich Gamma, published in 1992 by Springer. A numberof cooperating classes is understood as a framework, which represent theelements of a reusable design for a specific type of software. Aframework offers an architectural aid when dividing the design intoabstract classes and when defining their competences and interactions. Adesigner adapts the framework to a specific application by formingsubclasses of the framework classes and putting their objects together.Therefore a framework is used by a programmer for fixing the softwarearchitecture of a group of related applications. The reuse of a designcomplements the reuse of the code already known from the object-orientedsoftware design.

It is known from the article entitled “Framework—Basis einesAutomatisierungssystems” [Framework—A Basis for an Automation System] byGeorg Süss, published in etz, vol. 21/1998, pp. 22 to 25, that aframework not only makes possible a mutually used data storage, but alsopermits the realization of an integrated approach for the descriptionand matched execution of a total application in a distributedarchitecture. For this purpose, for automated applications a frameworkmust be based on Windows NT, in order to make possible the structuringof the total application into objects by the component object model andthe distribution of the components of a system via several computers bythe distributed component object model. In that case an automationframework offers the possibility of collecting the individual componentsof a distributed automation solution centrally in a system-wide datastorage. Therefore this information is immediately available to eachcomputer in an identical way. Moreover—in case of a subdivision of theapplication into individual objects—the framework provides themanagement of these objects and their assignment to individual networkstations. This makes possible the dynamic displacement of individualobjects at runtime, by which an improved utilization of the computerscan be achieved. Moreover, further stations can be dynamicallyintegrated into the application network for the running time by this.

It is known from the article entitled “Softwarekonzepte für einesteuerungsintegrierte Werkzeugüberwachung” [Software Concepts forControl-Integrated Tool Monitoring] by I. Suwalski, R. Urban and J.Burger, published in ZWF 92 (1997) 9, pp. 436 to 439, that the softwareframeworks have been developed from the area of object-oriented softwaretechnologies. A framework includes a number of cooperating classes,which determine the architecture of the application. Therefore, by usinga framework, the reuse of a design is stressed over the reuse of a code.Problem-specific algorithms are decoupled from the design by usingframeworks. The abstraction of the design of the system from theimplementation of problem-specific algorithms achieved by this makes afaster development possible, leads to similar structures and simplermaintenance. Furthermore clear, structured and lean documentation isalso made possible. This is explained by the example with frameworkswhich have predetermined the basic mechanisms of communication and thestructure of the implementation as a state model for individualprocesses. Flexibility is achieved by behavior models, whose algorithmiccharacteristics are implemented for the respective application.

SUMMARY AND OBJECTS OF THE INVENTION

It is therefore an object of the present invention to design a controlsystem in such a way, that the structure and the portion of theimplementation of the control software which is independent of themachine and control, can be adopted for the greatest possible number ofcontrol functions.

This object is attained by a control system of a numerically controlledmachine tool with a software structure, the control system including aprogram code of a control program specific to a machine tool and aframework that is independent of an application, wherein the frameworkis implemented in the form of a class library that has a first set ofclasses that define a functional structure of the control system. Asecond set of classes derived from the first set of classes of theframework, wherein the second set of classes contain the program codethat is specific to the machine tool and that implements applicationspecific functions of at least one of several functional groupsassociated with a man-machine interface, geometry processing, aninterpolator, movement processing and a programmable logic controller.

The control system in accordance with the present invention has theadvantage that the software designed as a framework is implemented as aclass library for a generic numerical control, which completely containsthe software structure of a generic numerical control. In this case, thesoftware structure of a generic numerical control includes the entirefunctional structure of the control software, but not the specificallyprogrammed functions. Uniform interfaces for the specific functions aredefined by the class library. The individual functions performed by thecontrol are implemented by a control-specific class, which has beenderived from a class in the class library. Because of this, this controlstructure can be transferred to different controls, even if the specificfunctions of other controls are completely different. The softwarestructure becomes reusable by abstracting the structure and the classlibraries (program with an executable code) from the specific functions.

The present invention will be explained in greater detail in whatfollows by the embodiment represented in the drawing.

BRIEF DESCRIPTION OF THE DRAWING

FIG. 1 schematically shows an embodiment of a control program accordingto the present invention, the control program being segmented intoinstantiations of derived classes.

The drawing FIGURE shows a possible division of the control program intoclasses, derived classes and instantiations of derived classes.

DESCRIPTION OF THE PREFERRED EMBODIMENT(S) OF THE INVENTION

The present invention will be explained in what follows by a simplenumerical control for a machine tool. Thereby it is unimportant for thestructure of the control software whether the machine tool is a millingcutter, a lathe, a grinder or eroding machine, or a processing center.

The control program for a numerical control, shown partially in agraphic form in FIG. 1, has been realized on the basis of a framework,wherein the framework is implemented by at least one class library 1.The essential functions of the control program of a machine tool can besubdivided into functional groups called geometry processing 1.2,interpolator 1.4, man-machine interface 1.1, movement control and aprogrammable logic controller.

In accordance with the present invention, a framework class library 1 isprovided. The class library 1 contains the software of a generic controlfor the individual abstracted functionalities and their interaction. Inthis case only the functional structure of the control program isdetermined by the class library 1; but the program code for the specificfunctions is not contained in the framework. This program code isdefined by the specific implementation of the classes in the form ofderived classes 1.1 to 1.4, wherein the essential characteristic is notthe structure, but the performed function and the program code requiredfor that. Therefore the existence of a function in the control program,and the interaction with other functions of the control program, isdefined by the framework. But the implementation of the function by theprogram code is not contained in the framework. This takes place in aderived class 1.1 to 1.4, which is derived from a class of the classlibrary and is integrated into the framework.

An application is realized by the implementation of the derived classes.For example, a derived class for an interpolator 1.4 is implemented,which is matched to a definite form of triggering the drive mechanisms.

Furthermore, the interaction, i.e. the cooperation, between individualderived classes 1.1 to 1.4 is realized by the framework as afunctionality of the generic control. This takes place viacommunications channels 2.1 to 2.5 between individual objects 1.1.1 to1.4.1, which are instantiations of the derived classes 1.1 to 1.4 of theframework, or the class library 1. Such a communications channel 2.1 to2.5 is implemented by mechanisms for data exchange known in the priorart. A determination is made by a communications channel 2.1 to 2.5,which objects 1.1.1 to 1.4.1 of the framework can communicate with eachother at all. Methods are already known in the prior art for definingwhich objects, as instantiations of derived classes 1.1.1 to 1.4.1,communicate with each other. There, this definition is a part of theimplementation of a specific control software.

The data format and the protocol of the transmission data is furthermoredefined by the framework, i.e. which data are transmitted through acommunications channel 2.1 to 2.5 between objects 1.1.1 to 1.4.1 of theframework. The interpretation of the transmitted data as parameters orcommands is performed by the derived classes 1.1 to 1.4.

If an already existing framework is used for producing a new controlprogram, the programmer already has framework classes 1 available which,for producing the control program for a specific control of a specificmachine tool, must be partially adapted to the latter, or implementedfor it. This occurs in that the programmer forms derived classes 1.1 to1.4 from the existing framework classes 1, and in this way creates anapplication.

The classes 1 of the framework define virtual functions, whoseimplementation takes place in the derived classes 1.1 to 1.4, or whoseimplementation can also be changed (overwritten) by the derived classes1.1 to 1.4, if needed. The implementation of the derived class 1.1 to1.4 takes place in that the programmer programs the implementations ofthis virtual function needed for the desired functionality and definesthe data (attributes) necessary for this.

In a second step of the implementation the programmer establishes fromwhich derived classes 1.1 to 1.4 objects 1.1.1 to 1.4.1 are generated,and which objects 1.1.1 to 1.4.1 communicate with each other. In thiscase the information as to which objects 1.1.1 to 1.4.1 are created andwhich communicate with each other, can exist in the derived classes, orcan be read out of an external data file or input by the user.

The basic mode of functioning is defined by the generic control andimplemented in the classes 1 of the framework. The specific functions ofa control result from calling up virtual functions of the genericcontrol during operations, and the result depending from the definiteimplementation is used again and, if required, transmitted to objects1.1.1 to 1.4.1, whose selection also is a function of the specificimplementation, as described above.

By the use of an already existing framework, the creation of a controlprogram is then limited to the programming of the technology- andmachine-specific functions to be performed in derived classes 1.1 to1.4, and the definition of the interaction between objects 1.1.1 to1.4.1 via communications channels 2.1 to 2.5.

Correspondingly, in the operation of a numerical control programmed inthis way, action is taken as represented in the drawing figure. Thegeneric control defined by the class library 1 of the framework has, forexample, inter alia the following functions:

-   -   Start of the control    -   Transmitting a message from a transmitter to a receiver and    -   Triggering the message processing at the receiver.

After a user has switched on the control, the objects 1.1.1 to 1.4.1needed for the application are created by the mechanism existing in theframework for generating derived classes 1.1 to 1.4. Furthermore, thestart function is called up in the class library 1 of the frameworkwhich, because of the functionality of the generic control, causes thecall-up of a start function in each created object 1.1.1 to 1.4.1. Inthis case it is possible to transfer a specific implementation to thestart function of a derived class 1.1 to 1.4.

For example, in the derived class 1.1, man-machine interface, a windowis opened by the start function, in which the user can make an input.This input is awaited, a message is formed from this input and thismessage is transmitted.

The positions of the machine shafts are maintained in the derived class1.4, interpolator, by the start function. For this purpose, the actualposition values of the shafts of the machine are determined and theseactual values are entered into the control circuit as setpoint values ofthe position.

A window for representing a simulated graphic illustration is opened bythe start function in the derived class 1.3, simulation.

The start function does not implement the derived class 1.2 of geometryprocessing (geo) and instead uses the implementation existing in theclass library.

As already explained, a message is sent by the man-machine interface1.1.1 as soon as an input is finished. This message is transmitted bythe framework via a communications channel 2.1 to the correct receiver,and processing of the message is triggered in the receiver by theframework.

In the course of the processing triggered in the respective objects1.1.1 to 1.4.1 following receipt of the message, a function defined inthe class library 1 of the framework is applied to the data transmittedin the message. This function must be implemented in each derived class1.1 to 1.4. The framework does not make an implementation available forthis.

In the geometry object 1.2.1, the data from a received message areinterpreted as positions to be approached, on the basis of whichparameters of the path curve are calculated and are transmitted as amessage.

These parameters of the path curve are passed on via a communicationschannel 2.2 to the interpolator object 1.4.1, by which the shaft drivesof the machine are controlled, and which transmits the approached pathpoints in the form of a message.

If message processing is triggered in the object 1.1.1 of theman-machine interface by the receipt of a new message, the received dataare interpreted as a position, which is displayed to the user.

If processing is only to be simulated, an object 1.1.2 is generated forthe simulation by the derived class 1.1, man-machine interface, whichpasses on the input data as a message to the simulation object 1.3.1.

During the simulation of processing, the simulation object 1.3.1conducts the appropriate calculations in accordance with the input andtransmits the approached path points in the form of a message.

This message is transmitted by the framework to the man-machineinterface 1.1.2 for the simulation. Based on the message processingtriggered there, the simulation data are displayed to the user.

A function from the class library 1 of the framework is called up forrealizing the transmission of a message. Since the conveyance ofmessages is a function of the generic control, there is no necessity,and also no possibility, of overwriting this function by a specificimplementation.

In accordance with the drawing figure, the control software can besubdivided. The class library 1 contains functions which are notspecifically designed for a control or a machine, for example thesending of a message.

Moreover, virtual functions are a part of the class library 1 which,based on the specific control hardware or machine mechanism, can begiven a specific design by the programmer of a derived class 1.1 to 1.4,such as the start function, for example, or must be given a specificdesign, such as the processing of a message, for example, so that theyinteract with the specific control hardware and/or machine mechanism.

The objects 1.1.1 to 1.4.1 are instantiations of the derived classes 1.1to 1.4 and contain the specific data for a specific function.

For example, the virtual function of the man-machine interface 1.1 wasinitially implemented for interacting with specific control hardware inorder to realize an input and output by specific hardware. Thereafter,the objects required for a man-machine interface for the simulation1.2.1, and one for processing 1.1.1, are created.

In order to achieve the required interaction via the communicationschannels 2.1 to 2.5, it must be known to the framework which of theseobjects 1.1.1 to 1.4.1 exchange messages with each other. For example,an object 1.1.1 for input sends messages to the object 1.2.1 for thegeometry calculation, and receives messages from the object 1.4.1 forinterpolation, while the instantiation 1.1.2 of the same class forsimulation exchanges messages with the object 1.3.1 for simulationcalculations.

The division into classes 1, derived classes 1.1 to 1.4 and objects1.1.1 to 1.4.1 made here represents only one of several options.Alternatively it would be conceivable, for example, that geometryprocessing and/or the interpolator are programmed independently of thehardware, so that these functionalities can be realized in a class 1.

By the division of the program code into one arranged in the framework,and a machine-specific program code outside of the framework describedhere, a differentiation is made for the functions of control between areusable structure, which is combined into a framework, and amachine-specific program code, which is implemented outside of theframework. The program code of the framework can be used in a group ofimplementations which differ in the control hardware used and in themachine mechanisms. In this case the degree of how far the differencesmay go is a function of the degree of abstraction of the framework.

Program codes of the derived classes 1.1 to 1.4 can only be transferredto other applications if compatibility is assured for at least thecontrol hardware and the machine mechanisms.

It is advantageous to implement the generally applicable functionalityof the control program for numerical control in the form of a frameworkin such a way as to be able to reuse the interaction of the classes 1and the derived classes 1.1 to 1.4 defined by the framework. Because ofthis, the complex linkages of the individual functions among each otherthrough the communications channels 2.1 to 2.5 can be reused.

The framework can additionally contain a mechanism for error treatment.A class with generic functions for error treatment is provided for thisin the framework, from which the derived class for error treatment iscreated by a machine-specific implementation of the functions. At leastone object is created by the generation of the functions of the derivedclass.

Since an error can occur with any arbitrary application of a function todata constituting an object, a communications channel from each objectto the object for error treatment is advantageously provided. Dependingon the functions existing for error treatment, communications channelsfrom the object for error treatment to the objects required for errortreatment must also be correspondingly provided.

If, for example, with any arbitrary error it is intended by a functionfor error treatment to prevent any movement of the machine controlled bythe control program, communications channels from all objects 1.1.1 to1.4.1 to the object for error treatment must be provided. By this it ismade possible that errors which can occur in any object can actually bedetected. Furthermore, a communications channel from the object forerror treatment must exist to the object 1.4.1, interpolator, throughwhich the movement control takes place in order to prevent any movementin case of an error.

Alternatively to stopping all axes of the machine it is also possible toprovide that a defined retraction path is traveled in case of an error,for example for removing the tool of a milling cutter from theworkpiece, so that no damage is caused to the tool or to the workpieceby the error. In that case a retraction movement is triggered in theinterpolator by the message of the object for error treatment to theinterpolator object 1.4.1, that an error has occurred.

When implementing a control which executes the control program inaccordance with the present invention, there is the option to design thecontrol as a divided system, in which portions of the control, andtherefore the control program, are executed at different locations bydifferent processors. In this case it is sensible to divide the controlprogram into processes, wherein at least one process is assigned to eachprocessor for execution. A mechanism for interaction across processborders is provided in the framework in this case. It is possible bythis mechanism that messages can be exchanged between objects ofdifferent processes. Thus, the process borders do not represent abarrier to the message exchange.

For example, for error analysis or for maintenance or repair jobs,portions of the control program can then run in a first process at thecontrol provider and can exchange messages by means of a portion of thecontrol program at the user, which is executed as the second process ofthe control program, over a general data net, for example the internet.

With divided systems, the mechanism for synchronization of the executionof the control program with incoming messages in particular, which iscontained in the framework, is of importance, wherein the sequence ofthe processing of incoming messages from independent communicationschannels is controlled. By this it is assured that the messages, whosedata are just then required by a function, are processed, or that—to theextent that no more urgent messages exist—the functions are executed,for which data are just then transmitted by a message. Furthermore, itis assured in this way by the framework that all messages are processed.

The framework in the form of a class library 1, and theapplication-specific functions in the derived classes 1.1 to 1.4 havebeen realized in accordance with the rules of object-orientedprogramming.

The invention may be embodied in other forms than those specificallydisclosed herein without departing from its spirit or essentialcharacteristics. The described embodiments are to be considered in allrespects only as illustrative and not restrictive, and the scope of theinvention is commensurate with the appended claims rather than theforegoing description.

1. A control system of a numerically controlled machine tool with asoftware structure, the control system comprising: a program code of acontrol program specific to a machine tool; and a framework that isindependent of an application, wherein said framework is implemented inthe form of a class library that comprises a first set of classes thatdefine a functional structure of said control system and wherein saidframework comprises a mechanism for error treatment that comprises: aclass with generic functions for error treatment provided in saidframework; and a class with a machine-specific implementation of saidgeneric functions derived from said class with generic functions; and asecond set of classes derived from said first set of classes of saidframework, wherein said second set of classes contain said program codethat is specific to said machine tool and that implements applicationspecific functions of at least one of several functional groupsassociated with a man-machine interface, geometry processing, aninterpolator, movement processing and a programmable logic controller.2. The control system in accordance with claim 1, wherein said frameworkcomprises a mechanism that forms objects as instantiations of saidsecond set of classes.
 3. The control system in accordance with claim 2,wherein said framework comprises a mechanism for interaction betweensaid objects.
 4. The control system in accordance with claim 3, whereinsaid mechanism for interaction between said objects includestransmission of messages over communications channels and causingprocessing of said transmitted messages at a receiver, wherein a dataformat and protocol of said transmitted messages are defined in anobject-independent manner.
 5. The control system in accordance withclaim 2, further comprising several processes which are independent ofeach other, and wherein said framework comprises a mechanism that causesinteraction between said objects across process borders.
 6. The controlsystem in accordance with claim 1, wherein said framework comprises amechanism for synchronizing execution of said control program withincoming messages, and said framework controls a sequence of processingof said incoming messages from independent communications channels.